Garbage Collection  >  Class Helpers  >  Contents

Class Helpers

Introduction

The .NET Framework is a rich hierarchy of classes and types. It contains a myriad of functionality, from collection classes, to string manipulation, to network communication, and a whole host of others. Borland's own VCL is also a rich framework, offering an equally wide range of functionality. The .NET Framework and the VCL framework are two class hierarchies with a similar goal: to relieve the programmer from having to re-implement commonly used patterns, algorithms, and utilities.

 

The migration of the VCL to the .NET platform has revealed that the two frameworks have much in common besides a similar design goal. The .NET Framework contains functionality that has been present in the VCL for years. So much so, that at first glance the .NET Framework might look like a complete replacement for the VCL. Indeed, one significant goal of the VCL migration is to leverage as much of the .NET Framework as possible. But merely replacing the VCL with the .NET Framework would not provide a suitable migration path for existing VCL users.

 

The .NET and VCL frameworks complement each other. A better migration solution is to allow VCL users to adapt .NET Framework classes -- create equivalent VCL classes -- and then add functionality expected by existing Delphi code, but not provided by .NET. The language feature that allows this form of extension is called a class helper.

 

A class helper is not a form of derivation; it does not introduce a new class type as such. A class helper introduces a new, wider scope for the compiler to use when resolving identifiers. When you declare a class helper, you state the helper name, and the name of the class you are going to extend with the helper. You can use the class helper any place where you can legally use the extended class. The compiler's resolution scope then becomes the original class, plus the class helper. To reiterate: a class helper is not a form of derivation. It is an alias for another class.

 

A good example of class helpers is the .NET class System.Object, and the VCL class TObject. In Delphi for .NET, TObject is not derived from System.Object, it is a helper for System.Object. The TObject helper introduces methods such as ClassName, and ClassType. This allows the .NET class to be used with existing Delphi code, which expects these methods. This would not be possible using the traditional technique of derivation.

 

Class helpers provide a way to extend a class, but they should not be viewed as a design tool to be used when developing new code. They should be used solely for their intended purpose, which is to adapt .NET classes to existing Delphi code. Component writers, who might be porting a Delphi component to the .NET Framework, will most likely encounter this scenario.

 

When porting a component, a developer might find a class in the .NET Framework that is very similar, but not exactly equivalent to the Delphi component. This is a case for using a class helper for the .NET Framework class, and then using the helper to extend that class with properties and methods in the Delphi component, but not in the .NET class. The result is a new Delphi component that will gain the benefits of the .NET platform, and, continue to run with existing code.

Using Class Helpers

The syntax for declaring a class helper is:

 

      ClassHelper = class helper [(ancestor list)] for type-id

      end;

 

A class helper is typically introduced with a type declaration:

 

      type

            TMyClass = Some.VerySimilar.Class;

 

Then you declare the class helper:

 

      // Introduce the class helper and declare the function expected

      // by existing Delphi code.

      TMyClassHelper = class helper for TMyClass

            function ExistingDelphiFunc : Integer;

      end;

 

Now, your existing Delphi code, which is expecting the type TMyClass to have a function called ExistingDelphiFunc, will continue to run. The bulk of functionality provided by TMyClass is now implemented in the original class (Some.VerySimilar.Class), and the compatibility code is implemented in the helper class.

 

Class helpers may introduce both class methods, and instance methods. For instance methods, the Self pointer is always the type of the extended class, not the class helper. In the example, the Self pointer would refer to TMyClass. Class helpers do not introduce a new type. Further, you will never create an instance of a class helper in your source code.

 

You can only create one class helper for a given class. However, when you declare the class helper, you can specify an ancestor list, which allows you to inherit functionality from other class helpers.

 


Top  |  Contents  |  Copyrights  |  Borland Developer Network  |  Borland Home